如果你去讀現在大部分談 AI 應用的文章,會發現它們有一個共同的隱含假設:

資源是無限的。

context 不夠?換一個更大的。額度不夠?升級方案。整批資料丟進去慢慢跑,反正跑得完。

我完全理解為什麼會這樣寫——因為在示範一個做法的時候,資源限制是雜訊。

但在我的實際情況裡,那個雜訊就是主線。

我的真實條件

講具體一點。

我用的是 VS Code 上的 Claude,額度是以五小時為一個窗口在計算的。用完了就得等下一個窗口。

為了知道自己還剩多少,我另外裝了一個看用量的延伸模組(Claude Code Usage)。它會直接告訴我這個窗口用掉多少。

而我給自己定的規則是:

用到 80%,就喊停。

但重點是那 20% 不是安全邊際

第一次講出這條規則的時候,聽起來像是一個很普通的風險控管——留兩成當緩衝嘛。

不是。那 20% 有很明確的用途:

它要留給我的正職工作。

我是 QA。這個知識庫專案不是我的工作內容,它是我在做完該做的事情之後,額外去做的東西。

而我白天的工作也需要用到同一個額度。看卡片、對程式碼、查一個 bug 的來龍去脈——那些事情不能等,也不能說「抱歉我額度用在別的地方了」。

所以那條 80% 的線,真正的意思是:

這個專案能用的,是我本業用剩的部分。

我覺得這件事值得被寫出來,因為它跟大部分 AI 專案的敘事很不一樣。那些文章裡的資源限制是成本問題——不夠就加預算。而我這裡的限制是排擠問題:多花在這裡的每一分,都是從別的地方挪過來的。

而下班之後,規則就變了

這條線還有一個很有趣的性質:它會換班。

下班以後,那個排擠不存在了。沒有工作要跟它搶,所以我就用好用滿——不留 20%,直接跑到底。

同一個專案,一天之內有兩種運作模式:

第三行是我後來才意識到的,而且它其實影響了我的排程:大規模抓資料、重建整包索引那種事,我都排在晚上。 白天做的都是可以隨時停下來的小事。

不是因為晚上比較安靜,是因為白天的那 20% 賠不起一個中途被砍掉的長工作。

額度怎麼變成架構

上面講的還只是使用習慣。真正有意思的是,這個限制怎麼改變了東西本身的形狀。

專案進行到某個階段,我寫下了這樣的要求:

「你規劃一下分階段讀取,每個階段結束後,等我確認額度用量。」

這句話在當下,只是一個很務實的省錢動作。

但它其實是一個架構決策,而且是這個專案最重要的幾個之一。

因為「分階段讀取」這件事一旦成立,後面所有東西都被決定了:

1. 如果不能一次讀完,那就得有辦法只讀需要的部分
2. 要能只讀需要的部分,就得先知道哪一部分是需要的
3. 要能事先知道,那些資料就必須先被切開、被標記、被索引
4. 而這些事情——只能在建置期做,不能在查詢的當下做

換句話說:

因為我付不起「每次查詢都重讀全部」,所以我只能把功夫花在「事先把東西整理好」。

而這正好就是整個專案後半段在做的事:切塊、建索引、預先產生摘要。

那些工作不是因為我覺得那樣比較優雅。是因為額度不允許另一種做法。

一個我沒有預期到的結果

這裡有一件事,我後來想起來覺得有點好笑。

如果當初我的額度是無限的,我大概會做出一個更糟的東西。

因為在沒有限制的情況下,最省事的做法一定是:把所有東西一次丟進去,然後問問題。 不用切、不用索引、不用想結構——反正它讀得完。

而 Day 10 那篇已經寫過那樣做會發生什麼事:一次餵進去的東西超過它能握住的量,中間會被壓縮、被丟掉,而被丟掉的部分不會跟你說一聲。

所以:

那個我以為在限制我的東西,其實擋掉了一個我當時看不出來的錯誤。

我不想把這件事講得太浪漫——限制就是限制,它讓很多事情變麻煩,我也真的因為額度不夠停下來過。

但它確實逼我提早面對一個問題:這些資料裡,哪些是這次真正需要的?

那個問題,如果不是被額度逼著,我可能要到很後面才會問。

所以如果要我給一句話

我會說:

在真實的專案裡,「能用多少資源」不是一個外部條件,它是一個設計輸入。

大部分 AI 應用的文章會先講方法,最後才附註一句「當然實務上要考慮成本」。

而我的經驗剛好相反:成本是第一個要考慮的,因為它決定了哪些方法根本不在選項裡。

而明天那篇,就是這件事最具體的一個後果。

明天:一句我照做很久,卻很晚才真的懂的規則

額度的限制,最後凝結成了我筆記裡的一句短話:

「先不要全讀,需要時再查。」

我一開始把它當成一個省資源的小訣竅,跟「記得關燈」差不多等級。

而它其實是這個專案最重要的幾個架構決策之一——而且我後來連它到底是不是我自己想出來的,都不太確定。